This invention relates generally to network address translation and proxy application control of network communication and, more particularly, relates to the combination of network address translation and proxy application functionality into a transparent application gateway process.
As the number of computers that needed or wanted to be connected to the Internet continued to grow, it soon became obvious that this number could not be accommodated by the number of available IP addresses, known as dotted-quads. In response to this address depletion problem, a method as illustrated in FIG. 2 was devised whereby a number of computers C1, C2, etc. could be located on a xe2x80x9cprivatexe2x80x9d network 60 and would use private IP addresses 62 to communicate with each other. These private IP addresses could be reused on other private networks since no one outside the private network could see these addresses. In order to allow the computers on the private network to communicate with other computes S1, S2, etc. on a public network, such as the Internet 64, the private network utilizes one machine 66 to provide the gateway for all of the computers on the private network to reach the public network. Through the use of the private addresses 62 on the private network 60 and the gateway computer 66, the address depletion problem is at least slowed.
This gateway computer 66 runs a program called a network address translator (NAT) that has both a private IP address 62 and a public IP address 68. As computers on the private network attempt to establish sessions with a server on a public network (or another private network), the NAT changes the source address 70 of the message packets 72 from the private address of the client computer to its public IP address. In this way, the private IP address is not communicated on the public network. The messages all appear to have come from the public IP address of the NAT machine. The NAT maintains a mapping 74 of the translation from the private to the public IP address so that when messages are received from the public network in response as illustrated by line 76, the NAT can forward them to the proper client machine. This operation of the NAT is completely transparent to the client computers on the private network, i.e. they each believe that they are communicating directly with the public servers.
FIG. 3 illustrates this redirect capability of the NAT machine. Specifically, a client machine C1 attempts to establish a session 78 directly with public server S1 as indicated by dashed line 80. However, when the message from C1 is detected by the NAT 66, it dynamically redirects 82 the message to S1 and changes the source address as described above. The client process does not know that the NAT has changed its messages"" source address, and continues to believe that it is communicating directly with the public server. Messages from the server S1 are dynamically redirected 82 to the client C1 based on the mapping of the address translation. As may be seen from FIG. 4, this address translation takes place at a low level, e.g. at the kernel level 84 in a Window""s architecture.
While the NAT has greatly alleviated the address depletion problem, especially for home and small business networks, its translation of source addresses is fixed within its programming. That is, the traditional NAT does not allow any application control of the address translations that it performs. Additionally, since the address translation is performed on the message packets at such a low level within the kernel 84, the NAT can add almost no value, other than providing the raw source address translation. The NAT cannot even provide any destination address translations, and does not fully support applications that either assume client and server addresses are both public and therefore equally accessible, or require that servers also initiate network sessions to clients. If added value is desired, such as centralized virus scanning, site blocking (parental-control filtering), white listing, caching (to speed up response-time), data-transformation (e.g. dithering of images to match screen size), etc., a proxy application must be used instead.
Traditional proxies, as illustrated in FIG. 5, are application programs existing in the user mode 86 that serve as the interface between the private 60 and the public 64 network (see FIG. 6). Unlike NATs, the proxy 88 must be addressed directly by the client machines as seen in the destination address field 90 of message packet 92, and therefore requires that the client applications C1, C2, etc. be setup to operate with a proxy 88. Many applications cannot do this, or require specific configuration changes to allow the use of a proxy, and therefore a proxy configuration may not be appropriate, or even possible, for use with all applications.
When a proxy application 98 is used, all communications are sent to the proxy in the user mode 86 (see FIG. 5) as illustrated by lines 94, 96. The proxy 98 then determines whether and to whom to forward the communication on the public network. If the proxy determines that the message may be passed to a server on the public network, the proxy establishes a second session 100, copies the data to the second session, changes the source and destination address, and sends out the message (see, also FIG. 7). In operational terms as illustrated in FIG. 7, a client process C1 establishes a first session 94 with the proxy 88 requesting access to a public server S1. If the proxy agrees, a second session 100 is established with the server S1 on the public network 64. Since all messages must pass from the kernel-mode network transport, e.g. TCP/IP 102, to the user-mode proxy 98, be copied to a second session, transferred back down to the kernel-mode driver 102, and finally transmitted to the network for the network application""s other session, a significant performance degradation occurs. However, proxy system promoters have begrudgingly accepted this performance degradation as the inevitable cost of the added value provided thereby.
Recognizing that the inability of various applications to utilize a proxy system precludes the adding of value to the network sessions using these applications, various software vendors have introduced transparent proxies. Transparent proxies operate like a traditional proxy in that they provide value to the network connection, and like a traditional NAT in that the network client need not specifically address them. The term transparent refers to the fact that the network client is unaware that its communication is being provided up to the proxy application. The client thinks that its communication is going directly to the network server, in much the same way as it does when a traditional NAT is used. However, the communication is actually redirected to the proxy application before being sent to the public network as illustrated FIG. 8.
As may be seen from this FIG. 8, as a client C1 on private network 91 attempts to contact a server S1 on a public network 64, the gateway machine 93 running the transparent proxy intercepts its messages. The transparent proxy operates by performing an address redirection through a traditional NAT 95 up to the proxy application 97. Once the proxy 97 has processed the message, it is passed back down to be sent to the server S1. While this redirection is transparent to the client thereby allowing operation of the proxy with clients whose applications would not allow operation with a traditional proxy, this redirection is fixed within the NAT 95. This requires that all communication be transferred up to the proxy at the application level or user-mode, and back down to the transport level or kernel-mode prior to being transmitted to the server. Therefore, the performance degradation of the traditional proxy discussed above still plagues the transparent proxy system.
The instant invention overcomes these and other problems by providing an application programming interface for intelligent transparent application gateway processes. Specifically, the inventive concepts of the instant invention relate to an intelligent transparent proxy that utilizes an application programming interface for translation of transport-layer sessions and an application programming interface for port-reservation routines to provide proxy services without requiring that client applications be notified of the proxy at all. More particularly, the inventive concepts of the instant invention relate to a generalized network address translator and associated application programming interface (API) that allow both source and destination address translations to be made. The API allows control of the NAT by the proxy thereby providing the benefits of both a proxy server and a network address translator (NAT) while minimizing the transmission delays normally associated with traditional and transparent proxies.
With the intelligent transparent proxy of the instant invention, client applications do not know that they are communicating through a proxy, and therefore need not be configured to do so. This is accomplished by the instant invention by allowing the proxy to dynamically command a generalized NAT to effect both source and destination address translations to, essentially, reroute data flow up through the proxy without the client knowing. The address changes are mapped in the gNAT, and result in apparent sessions between different clients and servers. As the proxy identifies data transfers that need not be processed by the proxy, the proxy commands a dynamic address translation at the transport layer. This bypasses the necessity of transferring the data up to the proxy, thereby greatly increasing the performance of the system.
As an example of the operation of the intelligent transparent gateway of the instant invention, assume that a client application wanted to establish a session from itself to a server on a public network. The message would hit the translation mapping of the gNAT, and be converted to a message from client to the transparent gateway. The transparent gateway would pass the message up to the proxy for servicing. The proxy is able to then service the message itself, deny transmission of the message, pass the message on without modification, etc. If the message is forwarded to the server, it appears to have originated from the gateway. The translation mapping is recorded so that any return messages may be forwarded to the client application, if the proxy determines that it is appropriate to do so. This forwarding may require servicing by the proxy or may be passed without servicing, dependent only on the proxy commanded translation in the gNAT. This control provided to the proxy is unknown in prior systems.
Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying figures.